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Pursuant to 37 C.F.R. 1 .8, 1 certify that this correspondence is being deposited with the U.S. Postal Service in an envelope addressed 
to: Commissioner for Patents, P.O. Box 1450, Alexandria, VA 223 13-1450 on the date below: 

Date Nine 



RESPONSE TO FINAL OFFICE ACTION MAILED JULY 1, 2005 

MAIL STOP AF 
Commissioner for Patents 
P.O. Box 1450 

Alexandria, VA 22313-1450 
Dear Sir: 

Applicant submits this paper in response to the Final Office Action dated July 1, 2005. This 
response is being filed with two-months; therefore, an Advisory Action is respectfully requested. 

Should any fees under 37 CRF 1.16-1.21 be required for any reason relating to the enclosed 
materials, including any additional fee for an extension of time, the Commissioner is authorized to deduct 
such fees from O'Keefe, Egan & Peterman Deposit Account No. 10-1205AVRKS:002. 

Please amend the application as follows: 
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Amendments to the Claims 

Please amend the claims as set forth in the following listing. This listing of claims will replace all prior 
versions, and listings, of claims for the present application: 

1. (Currently amended) A method for providing server-based purchasing management utilizing payment 
id e ntifiers cards and dynamic approval parameters, comprising: 

receiving at one or more server systems within a purchasing management system for an entitv a 

plurality of electronic purchase requests from requestors systems within m tfie entity; 
evaluating the plurality of purchase requests with respect to the entity's purchase policies to 

provide approval processing utilizing one or more server systems; 
generating a plurality of sets of approval parameters based upon the approval processing 

utilizing one or more server systems, each set of approval parameters being associated 

with an approved purchase request; and 
dynamically storing each set of approval parameters with respect to at least one payment 

id e ntifier card so that purchases using payment identifiers cards may be processed by a 

payment processing system in view of approval parameters associated with those 

payment identifiers cards . 

2. (Original) The method of claim 1, fiirther comprising providing access through a network to a plurality 
of customizable purchasing management rules residing on one or more server systems, receiving through 
the network the plurality of purchase requests and applying the purchasing management rules to the 
purchase requests to help generate the approval parameters for approved purchase requests. 

3. (Original) The method of claim 2, further comprising notifying an approver of a purchase request, if 
some action is required from the approver for the purchase request to be approved, and allowing the 
approver to take the required action through a network accessible approval mechanism. 

4. (Original) The method of claim 3, further comprising allowing the approver to, identify, at least in part, 
the approval parameters for the approved purchase request. 
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5. (Original) The method of claim 1, wherein the purchase requests comprise requests for purchases of 
products or services from network enabled markets. 

6. (Original) The method of claim 1, wherein the purchase requests comprise requests for purchases of 
products or services from non-network enabled markets. 

7. (Currently amended) The method of claim 1, wherein the payment identifiers cards comprise payment ? 
credit cards. 

8.. (Previously presented) The method of claim 1, further comprising utilizing the payment id e ntifi e rs 
cards as requestor specific identifiers and wherein the purchase requests include an indication of the 
payment id e ntifier card of the requestor. 

9. (Original) The method of claim 2, wherein the network comprises the Internet. 

10. (Currently amended) A method for providing server-based purchasing management services to 
customer entities through a network, comprising: 

providing access through a network to a plurality of customizable purchasing management rules 
residing on one or more server systems, the purchasing management rules providing 
approval requirements for purchases requested by requestors associated with a customer 
entity; 

receiving through the network a purchase request from a requestor; 
applying the purchasing management rules to the purchase request; 

notifying an approver of the purchase request, if the purchasing management rules require action 

by the approver for the purchase request to be approved; 
allowing for the approver to take approval action through a network accessible approval 

mechanism; and 

generating a set of approval parameters for an approved purchase request and dynamically 
associating the set of approval parameters with a payment id e ntifier card . 

11. Canceled. 

12. Canceled. 
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13. (Currently amended) The method of claim 10, further comprising conmiunicating the set of approval 
parameters to a payment processing system for storage and use in payment processing with respect to a 
vendor transaction corr e lating a purchas e mad e using the payment identifier with the approval parameterg 
and appro^ang the purchas e if th e purchase is vs'ithin the approval parameters . 

14. (Original) The method of claim 13, wherein the approval parameters comprise an identity of a 
vendor for a requested product or service and a maximum cost amount for the product or service. 

15. (Currently amended) The method of claim 10, wherein the payment id e ntifier card comprises a 
payment credit card. 

16. (Previously presented) The method of claim 15, further comprising providing a plurality of payment 
cards to a plurality of requestors within an entity so that each request may utilize the payment card in 
making purchase requests and in executing approved purchase requests. 

17. (Original) The method of claim 10, wherein the receiving step comprises receiving a purchase 
request from a network enabled market, the network enabled market allowing the requestor to identify 
and select for purchase products or services through the network. 

1 8. (Previously presented) The method of claim 17, further comprising allowing the approver to 
determine one or more approval parameters associated with an approved purchase request from the 
network enabled market. 

19. (Original) The method of claim 10, wherein the receiving step comprises receiving a purchase 
request from a market that is not network enabled, the purchase request identifying one or more details 
concerning a need that the purchase request will address. 

20. (Previously presented) The method of claim 1 9, further comprising allowing the approver to 
determine one or more approval parameters associated with an approved purchase request from the non- 
network enabled market. 

21. (Original) The method of claim 10 wherein the network comprises the Internet. 
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22. (Currently amended) A server-based purchasing management system utilizing payment id e ntifi e rs 
cards to provide control over purchases of a oustomer an entity, comprising: 

one or more server systems configured to provide a purchasing management system for an entity, 
to receive a plurality of electronic purchase requests ifrom a plurality of requestors 
systems within an entit y, to conduct approval processing of these purchase requests 
according to purchasing policies of the entity, and to generate a plurality of sets of 
approval parameters associated with the plurality of purchase requests based upon the 
approval processing: and 
a plurality of payment identifi e rs cards, at least one dynamic payment id e ntifi e r card being 

associated with each set of approval parameters, the payment identifiers cards allowing 
purchases made using a payment id e ntifi e r card to be correlated with an appropriate set 
of approval parameters; 
wherein the one or more server systems are further configured to cause each set of approval 
parameters to be stored with respect to at least one payment id e ntifier card so that 
purchases made using a payment identifier card may be processed by a payment 
processing system in view of approval parameters associated with that payment identifier 
card . 

23. (Previously presented) The purchasing management system of claim 22, wherein the one or more 
server systems are further configured to receive through a network the plurality of electronic purchase 
requests. 

24. (Previously presented) The purchasing management system of claim 22, wherein the one or more 
server systems are further configured to provide access through the network to a plurality of 
customizable purchasing management rules residing on the server systems and to apply the purchasing 
management rules to the purchase requests. 

25. (Currently amended) The purchasing management system of claim 22, further comprising one or 
more payment processing systems configured to store the plurality of sets of approval parameters and the 
associated dynamic payment id e ntifiers cards, to receive details of a purchase made using a dynamic 
payment identifier card, to evaluate the purchase against an appropriate set of approval parameters for the 
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purchase request associated with the purchase, and to approve the purchase if the purchase falls within 
the approval parameters. 

26. (Currently amended) The purchasing management system of claim 22 wherein the payment 
identifiers cards comprise paym e nt credit cards. 

27. (Original) The purchasing management system of claim 22, wherein the purchase requests comprise 
requests for purchase of products or services from network enabled markets. 

28. (Original) The purchasing management system of claim 22, wherein the purchase requests comprise 
requests for purchase of products or services from non-network enabled markets. 

29. (Previously presented) The purchasing management system of claim 22, wherein the network 
comprises the hitemet. 

30. (Currently amended) A network accessible purchasing management system, comprising: 

one or more server systems accessible through a network that are configured to provide access to 
a plurality of customizable purchasing management rules residing on the server systems; 

a purchase request subsystem within the server systems configured to receive purchase requests 
through the network; 

an approval processing subsystem within the server systems configured to apply the purchasing 
management rules to the purchase requests and to allow an approver to take approval 
action, if the purchasing management rules require action by the approver for a purchase 
request to be approved; and 

a dynamic purchase processing subsystem within the server systems configured to generate 

approval parameters for approved purchase requests and to dynamically associate a set of 
approval parameters for each purchase request with a payment identifi e r card to be 
utilized for purchase of the product or service identified in the purchase request. 

31. Canceled. 

32. (Currently amended) The network accessible purchasing management system of claim 30, further 
comprising one or more payment processing systems configured to store a plurality of sets of approval 
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parameters and associated payment identifi e ro cards, to receive details of a purchase made using a 
payment identifier card, to evaluate the purchase against an appropriate set of approval parameters for the 
purchase request associated with the purchase, and to approv e allow the purchase if the purchase falls 
within the approval parameters. 

33. (Currently amended) The network accessible purchasing management system of claim 30, wherein 
the payment id e ntifi e rs cards comprise payment credit cards. 

34. (Original) The network accessible purchasing management system of claim 33, wherein the approval 
parameters comprise an identity of a vendor for a requested product or service and a maximum cost 
amount for the product or service. 

35. (Original) The network accessible purchasing management system of claim 30, wherein the network 
comprises the Internet. 
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REMARKS 



Status of Claims 

Claims 1, 7, 10, 13, 15, 22, 26, 30, 32 and 33 have been amended. Claims 1-10, 13-30 and 32-35 
are currently pending in the case. 

Amendments to the Claims 

Claims 1,13, 22, and 32 have been amended to clarify the claimed inventions. With respect to 
independent claims 1 and 22, amendments have been made to clarify that the approval parameters in 
those claims relate to the results of approval processing of purchase requests according to an entity's 
purchasing policies by one or more server systems. Similar limitations to those added to claims 1 and 22 
can be found in other claims, such as claims 2, 10, 24 and 30. In addition, the clarifying amendment 
from payment "identifier" to payment "card" is based upon limitations in dependent claims 7, 15, 26 and 
33. As such. Applicant respectfully requests that these claim amendments be entered, even though after 
final rejection, and that the amended claims be considered in the Advisory Action. 

Rejection of Claims 

Claims 1-10, 13-30 and 32-35 were rejected under §102 as anticipated by U.S. Patent No. 
6,226,624 (W atson). Applicant respectfully traverses these rejections. 

Initially, it is noted that the Office Action confuses transaction "authorization" processing and 
purchase request "approval" processing, which are two distinctly different processing operations. As 
used in Watson, transaction "authorization" is a process where a merchant seeks information from an 
authorizing agent about an account being used by a purchaser to make a transaction and where the 
merchant receives back an authorization code if the account is in good standing and the transaction is 
within the account parameters. How to handle this authorization process is the sole focus of Watson. In 
contrast, "approval" processing for purchase requests within an entity, as used with respect to the present 
invention, refers to a process where purchase requests within an entity are evaluated against that entity's 
purchasing policies to determine whether the purchase request is to be approved by the entity as an 
appropriate corporate expenditure. Once approved, the purchase request can then be fulfilled through a 
transaction that involves transaction "authorization" processing. Thus, transaction "authorization" 
processing is distinctly different from purchase request "approval" processing. 
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As stated above, Applicant has amended the claims to help clarify the claimed invention with 
respect to distinctions between "approval" processing of purchase requests within an entity and 
transaction "authorization" processing of merchant transaction authorization requests. 

The present invention is directed to "approval" processing according to purchasing policies of an 
entity in order to generate approval parameters according to the entity's purchasing policies. In addition, 
the present invention is directed to the use of these dynamic policy-based approval parameters in later 
payment processing of the actual vendor transaction. For example, as discussed in the Specification: 

Dynamic approval parameters for any particular purchase request are produced after applying the 
company purchase policies to those purchase requests within a purchasing management system. 
By utilizing dynamic approval parameters linked to specific purchase requests, as opposed to 
general static approval limitations available with existing purchasing cards, the systems and 
methods of the present invention allow for the efficient management and control of company 
purchases, regardless of where the purchase is made, without sacrificing the safety of having 
purchase requests reviewed under standard company purchase policies. 

[Specification, page 12 (emphasis added).] In short, although the payment processing aspects of the 
present invention relate to accepting (z.e, authorizing) or denying a merchant transaction request, the 
purchasing management aspects of the present invention relate to approval processing of purchase 
requests according to purchase policies of a company and how to tie the policy-related approval 
parameters that result from this approval processing to the later payment processing that is associated 
with the actual transaction at a vendor or merchant. 

Watson, in contrast, does not address approval processing according to company purchasing 
policies. Rather, Watson is focused solely on how to handle authorization and pre-authorization of the 
actual merchant transaction. Li contrast with policy-based approval parameters of the present invention, 
therefore, the pre-authorization parameters of Watson are based solely upon actual or approximated 
quotes from a merchant. [Watson, col. 9, Ins. 51-60.] 

More particularly, Watson appears to discuss three basic transaction embodiments: (1) account 
user initiated purchases (FIGS. 2A-B), (2) account manager initiated purchases (FIGS. 6A-B), and (3) 
web user initiated purchases (FIGS. 8A-B). The first two embodiments appear to be directed to possible 
corporate environments where an account manager obtains a quote from a merchant and then the account 
user or the account manager initiates the purchase with the merchant, respectively. The last embodiment 
appears directed to individual consumers and is designed for the particular problem of consumer 
purchases of goods and services from Litemet websites. 
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With respect to the first two embodiments of FIGS. 2A-B and 6A-B, Watson discloses systems 
and method for allowing an account manager to make pre-authorization requests for specific transactions 
through a computer connection to a card issuer. As described in Watson, during account set-up activities 
with the card issuer, certain categories of goods and services are designated with "pre-authorization 
SICs" that denote transaction categories for which pre-authorization will be required. [Watson, col. 5, 
Ins. 21-26.] The "pre-authorization transaction phase" then begins with an account manager 202 
generating a quote from a merchant for goods and services desired by an account user 204. [Watson, col. 
9, Ins. 47-60.] Based upon this merchant quote, the account manager 202 sends a pre-authorization 
request 224 to the card issuer 214, and the card issuer 214 then sends a pre-authorization request to an 
authorizing agent 212. [Watson, col. 9, Ins 60-64; col. 10, Ins. 28-33.] The authorizing agent 212 then 
stores pre-authorization parameters in a pre-authorization table 318. [Watson, col. 10., Ins. 33-37.] 
When the transaction is initiated at the merchant, the merchant sends a transaction authorization request, 
and the authorizing agent uses the pre-authorization table to process this request only if the transaction 
authorization request presents an SIC (standard industrial code) that has been previously designated as a 
pre-authorization SIC. [Watson, col. 6, Ins. 48-55; col. 10, Ins. 33-37.] 

With respect to the embodiment of FIGS. 8A-B, Watson discusses a web account user or 
consumer version of the system for purposes of Internet shopping. In particular, in this consumer 
version, a web account user or consumer 804 contacts a card issuer 814 to obtain a pre-authorization 
account or to designate pre-authorization SICs, engages in "traditional shopping or browsing" such as 
Internet shopping, determines the desirability of a web merchant's good or service, accesses an 
authorization web page 815, and enters specific parameters for the transaction through that web interface. 
[Watson, col. 17, bi. 47 to col. 18, In. 19.] The authorization web page 815 then forwards a pre- 
authorization request to the authorizing agent 812. [Watson, col. 18, Ins. 16-19.] The authorizing agent 
then stores pre-authorization parameters in a pre-authorization table 918 associated with the consumer 
account. [Watson, col. 18, Ins. 43-59.] Following this pre-authorization phase, the web account user 804 
returns to the web merchant page 806 to consummate the transaction. [Watson, col. 18, Ins. 20-23.] Once 
the transaction is initiated at the merchant, the merchant sends a transaction authorization request, and 
the authorizing agent uses the pre-authorization table to process the transaction. [Watson, col. 18, Ins. 
27-32; col. 15, Ins. 58-61.] 
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As can be seen from these embodiments (FIGS. 2A-B, 6A-B and 8A-B), therefore, there is 
simply no teaching or suggestion in Watson to achieve or implement automated approval processing of 
electronic purchase requests according to an entity's purchasing policies in order to generate policy- 
based approval parameters that can be used for later payment processing thereby tying corporate 
purchasing policies to actual merchant transactions, as provided by the present invention. 

In relying upon Watson to reject the pending claims, therefore, the Office Action improperly 
equates or confuses "authorization" processing for merchant transaction authorization requests with 
"approval" processing for purchase requests according to an entity's purchasing policies within an 
entity's purchasing management system. 

For example, with respect to claim 1, the Office Action points to pre-authorization requests from 
an account manager to a card issuer as an example of "a plurality of electronic purchase requests from 
requestors within an entity." [Office Action, page 3.] As stated above, pre-authorization requests relate 
. to the processing ultimately to be done by the authorizing agent as part of the final merchant transaction 
and are not purchase requests from within an entity. Again with respect to claim 1, the Office Action 
points to- the pre-authorization request and associated account number as meeting the step of "evaluating 
the plurality of purchase requests with respect to an entity's purchase policies utilizing one or more 
server systems." [Office Action, page 3.] As stated above, this information relates to "authorization" ' 
processing, and Watson provides no teaching with respect to "approval" processing. In Watson,, there is 
no discussion of an entity's purchasing policies, no discussion of evaluating purchase requests based 
upon those purchasing policies, and no discussion of generating approval parameters based upon this 
approval processing as part of a purchasing management system within an entity. Still further, the Office 
Action equates the pre-authorization parameters of Watson with the step of "generating a plurality of sets 
of approval parameters utilizing one or more server systems." [Office Action, page 3.] Although the 
approval parameters of the claimed invention are subsequently used for transaction processing by a 
payment processing system, these approval parameters are based upon the results of approval processing 
according to an entity's purchase policies. In contrast, the pre-authorization parameters of Watson are 
based solely upon actual or approximated quotes from a merchant. [Watson, col. 9, Ins. 51-60.] 

Continuing on to dependent claim 2, the Office Action points to the account manager and a 
computer connected to the card issuer as meeting limitations directed to providing network access to 
purchasing management rules, receiving purchase requests, and applying the purchasing management 
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rules to generate the approval parameters. [Office Action, page 4.] This argument in the Office Action 
again confuses transaction "authorization" processing as part of a merchant transaction with "approval" 
processing of purchase requests according to an entity's purchasing policies. As stated above, 
authorization and pre-authorization, as used in Watson, refer to the acceptance or denial of an actual 
transaction authorization request from a merchant. [Watson, col. 8, Ins. 36-41.] What Watson does not 
discuss is approval processing of purchase requests within an entity according to an entity's purchasing 
policies as would occur within the purchasing management system 100 of the present invention. 

With respect to claim 3, the Office Action points to an authorizing agent who receives 
authorization requests from a merchant in Watson as "an approver" within a purchasing management 
system. [Office Action, pages 4-5.] Again, the authorizing agent of Watson acts to authorize or deny an 
actual merchant transaction. In contrast, the approval processing in the presently claimed invention 
addresses automated approval processing of a purchase request according to an entity's purchasing 
policies. Payment processing of the actual transaction would occur at a later time based upon these 
policy-based approval parameters. 

Looking to independent claim 10, the Office Action relies upon the pre-authorization parameters 
communicated by the account manager to the card issuer and upon the authorization request from a 
merchant transaction as meeting the limitations of the claim. [Office Action, page 6.] As stated above, 
however, the "approval" processing limitations addressed in claim 10 are simply not met or even 
addressed by the systems described in Watson that focus solely on "pre-authorization" and 
"authorization" of merchant transactions. This conftision between ' transaction "authorization" and 
purchase request "approval" processing continues with respect to the claims that depend from claim 10. 

Independent claims 22 and 32, which are not individually addressed in the Office Action, require 
similar "approval" processing related limitations to those in independent claims 1 and 10. And claims 
that depend from claims 22 and 32 further include approval processing related limitations. 

In short, Watson does not teach or address purchase request approval processing according to 
purchase policies of an entity as part of a purchasing management system, does not address the creation 
of approval parameters according to an entity's purchasing policies as part of this approval processing, 
and does not address the later use of these policy-based approval parameters for payment processing. In 
contrast, the claimed invention requires purchase request approval processing according to purchasing 
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policies of an entity as part of a purchasing management system for the entity. This automated approval 
processing leads to creation of approval parameters according to the entity's purchasing policies. And it 
is these policy-based approval parameters created through approval processing that are later utilized by a 
payment processing system to accept (i.e., authorize) or deny a merchant transaction. 

Based upon the above reasons, therefore, Applicant respectfully asserts that Watson does not 
teach or suggest the presently claimed inventions. Removal of the pending rejections and an indication 
of allowability for the pending claims are respectfully requested. 



Applicant respectfully asserts that the pending claims are in condition for allowance. 
Reconsideration of the application is respectfully requested. 

The Examiner is invited to contact the undersigned at the phone number indicated below with 
any questions or comments or to otherwise facilitate expeditious and . compact prosecution of the 



O'KEEFE, EGAN & PETERMAN 
1101 Capital of Texas Highway South 
Building C, Suite 200 
Austin, Texas 78746 
(512) 347-1611 
FAX: (512) 347-1615 



Conclusion 



application. 



Respectfully submitted, 




■Brian W. Petierman 
Reg. No. 37,908 
Attorney for Applicant 
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